NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/lang/c-part1/9046

Internet Message Format | 1996-08-05 | 3.7 KB

Path: rcp6.elan.af.mil!rscernix!danpop
From: [e-mail] (Dan Pop)
Newsgroups: comp.lang.c
Subject: Re: Tradition or what?
Date: 7 Mar 96 15:09:47 GMT
Organization: CERN European Lab for Particle Physics
Message-ID: <danpop.826211387@rscernix>
References: <4g0elg$[e-mail]> <4h0bbo$[e-mail]> <4h7ce0$[e-mail]> <4h85sm$[e-mail]> <danpop.825961872@rscernix> <[e-mail]>
NNTP-Posting-Host: ues5.cern.ch
X-Newsreader: NN version 6.5.0 #7 (NOV)

In <[e-mail]> Larry Weiss <[e-mail]> writes:

>Dan Pop wrote:
>>
>> In <4h85sm$[e-mail]> Teresa Reiko <[e-mail]> writes:
>> >Here are the three worst Microsoft coding rules, in my opinion at least:
>> >Every line of code must contain a comment.
>> >Any number greater than 2 must be a named constant.
>> >No procedure may be longer than 25 lines.
>
>
>> Actually, the second rule is quite good (except that '2' should be replaced
>> by '1' :-)  Magic constants embedded in the code are a huge nuisance
>> for maintenability.  If you have to change an explicit (aka magic) constant
>> in a piece of code, how can you be sure that you aren't going to break
>> anything?  By changing a macro definition, you _know_ that you won't
>> break anything, because all the dependencies of that macro will be
>> automatically taken care of by the compiler (and your "make" utility).
>
>I agree that there are good uses for giving a literal a name, and using
>that name instead of repeated usage of the literal, but to make a
>mandate that even if the literal were referenced only once you must give
>it a name would seem too extreme.

The point is that software is not usually cast in concrete.  What you
thought to be a one-time magic constant might be used later (in a
future release/version of the program) in another place and, if you
don't follow the rule, chances are that it will be used again

>In the environment of named literals, I must always refer back to the
>mapping.

Not always, only when the actual value is of any interest.  In the vast
majority of cases, it isn't.  Finding a macro definition with grep is
trivial, you can even put a wrapper around grep.

>Now you would say, fine, just deal with the abstraction and
>not the actual value, but what I lose is the ability to readily make
>comparisons to other literal values when they just have names.   I can't
>readily see the proportions and other relative associations that are
>usually there in the code.   I no longer have an immediate grasp of
>the qualities of "small" or "large"  or maybe "unusually large" if all
>is hidden in an abstract, one string fits all name.

More often than not, this is irrelevant to the maintenance of a software
package.  When it isn't, see my previous paragraph.

>When there are errors
>in the #define of the literal's name, these can be very hard to detect,
>as they are hidden away in the header file.

They're as easy to detect as errors in magic constants.  Many compilers
will even display the line as it looks after preprocessing, to help you.
Anyway, whenever I use a macro definition which is not trivial, I test
its correctness separately, to be sure that it is OK.  But we were talking
about trivial macro definitions here, where a plain constant is put behind
a (symbolic and hopefully meaningful) name.

A well chosen name says a lot more to the programmer and maintainer than
an arbitrary constant.

>Anyway, I'm just saying teach the concept of named literals and then let
>the programmer make the decision on a case by case basis.

This is not how coding rules/standards work :-)

Dan
--
Dan Pop
CERN, CN Division
Email: [e-mail]
Mail:  CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland